This invention relates to the analysis of events in a communication system. In following description, an event is an object that represents activity in a communication system. An event is not merely a message but may also contain related data, for example a parameter describing the activity that the event represents. Typically, an event might be represented by a data structure having an event id, to identify the event; event type field, which defines the type of event; an event timing field, which defines the time at which the event occurred; and optionally an event parameter field, which contains further information about the activity the event represents. Events have the same relationships to one another, for example the relative timing of events or a causal relationship between events, as the activities represented by the events.
In some embodiments, the term event relates to Operation & Maintenance (O&M) events, e.g. objects carrying information about O&M occurrences, in a communication system. In an exemplary mobile radio communication system, one definition of an event is:                An object or signal carrying information about any discernable occurrence that has significance for the management of the mobile radio infrastructure or the delivery of service and evaluation of the impact a deviation might cause to the services.        
Events may be used to monitor network and service performance, and provide statistics for a network operator to analyze the operation of the network. In particular, an event based application processing events generated by the communication system may provide: important statistical indicators of the network performance in real time; as well as solutions for long time storage of detailed network statistics; and information enabling detailed trouble-shooting of the network.
Monitoring the occurrence of a burst of events representing O&M activities of communication systems is significant since detection of an event burst can be very useful in spotting system problems or bottlenecks.
In general, a burst of events is considered to occur when the frequency of occurrence of that event in a data stream rises significantly, relative to the normal frequency of occurrence, within a short time period, and may last for a certain period. A temporary pulse of events may be caused by many factors and is unlikely to indicate the existence of a problem or a deterioration in user service experience.
When considering time-series data, such as events in a communication system, one important indicator of change in the communication system is the presence of bursts of events. In particular, depending on the volume and the triggers, an excessive number of events with failure code parameters may be a valid indication of failures in the nodes or links between nodes of the system, and an excessive number of non-failure events, e.g. without failure code parameters, may indicate changes in a system, such as congestions, before any failure occurrences. Therefore, the identification of bursts can provide useful insights about a change in the monitored service quality and/or network performance, allowing the operators to act in a timely manner to make an informed decision.
However, reliable detection of event burst behaviour that is indicative of an event burst occurrence in communication systems has the following challenges:
Firstly, it is generally recognized that network access and service usage can vary widely when considered over different timescales. This leads to the frequency of event occurrence varying significantly when measured over different time periods.
In addition, different types of events have varied occurrence behavior, and different degrees of significance. Some types of events may occur more frequently than others and with more normal variability and therefore it is not possible to determine the burst behavior of events by simply counting and comparing the absolute number of occurrences of each event.
Finally, event processing may impose significant performance requirements since mobile radio systems and/or fixed IP networks may generate a high-volume of events, for example at a rate of 60 k events per second. Handling such a high volume of events requires high performance applications with as little storage space and memory consumption as possible.
Existing event processing methods in mobile radio systems or fixed networks include:
A first method of event processing relies on calculating a simple success/fail ratio and is the most straightforward way of event processing. For example to determine an attach success ratio the number of successful attach attempts is divided by the total number of attach events, as shown:
      AttachSuccessRatioSGSN    ⁢                  [    %    ]    =                    Number        ⁢                                  ⁢        of        ⁢                                  ⁢        successful        ⁢                                  ⁢        Attach        ⁢                                  ⁢        attempts                    Total        ⁢                                  ⁢        number        ⁢                                  ⁢        of        ⁢                                  ⁢        Attach        ⁢                                  ⁢        attempts              ×    100  
Although simple, ratio calculation only provides a summarized view of service performance and the calculated results can be misleading. In particular, the frequency of occurrence of events is naturally variable and calculating average failure or success ratio may lead to identical results for events with different levels of event occurrence variability.
A second method of event processing relies on defining and configuring one or more counters. When processing events, different counters are updated depending on the processed events. At regular points, controlled by a granularity period parameter, the counter values are sampled, collected in a report and reset. These reports are subsequently output as separate files. The set of counters to be calculated is manually selected. It is possible to apply filters, for example, to only count the number of events with a certain parameter set to a certain value. Filter criteria can be single value criteria or multi-value criteria, in which the filter passes the event if any value in the multi-value list matches against the specific event parameter.
In order to monitor events for each attribute value (for example, unsuccessful attach events with cause code 13), one counter can be created for each selected filter value (e.g. distribution).
Counter based analysis approaches, although popular, have their inherent constraints.
First, it may not be possible to correlate the results from different counters in the system on session basis since typically counters lack good correlation characteristics. It is difficult to create service quality measurement and carry out problem diagnosis based on counters.
Second, counter based event analysis introduces bottlenecks for the system. Scalability in storage and processing is one of the most challenging issues of event based applications. The values of the counters are meaningless unless they are further analyzed, requiring additional processing resources. By selecting distribution over several attribute values in multiple attributes, the total number of counters created is the product of the number of filter values for each attribute. This can create a very large number of counters from a single monitor, leading to significant complexity when problem diagnosis is carried out.
Third, typically the counters are calculated based on fixed intervals, for example at interval values of 5, 15, 30 and 60 minutes. On the one hand, burst detection requires fairly short intervals between counter calculations since even a 5 minute interval when an event burst occurs may impact the accuracy of problem analysis. However, the shorter the fixed interval, the more data is produced by the counter, which imposes further storage & processing overhead on the systems. In many arrangements it is very hard to select a counter interval that balances granularity and the storing and processing overhead in counter based approaches.
A third method is complex event processing (CEP), which is primarily an event processing concept that processes multiple events with the goal of identifying the meaningful events within the event cloud using techniques such as detection of complex patterns of many events, event correlation and abstraction, event hierarchies, and relationships between events such as causality, membership, and timing, and event-driven processes.
However, existing complex event processing methods in event causality & pattern discovery are mainly manually based. Considering the nature of the events in mobile radio systems and fixed IP networks, it might be very difficult to manually define and maintain rules and policies for event correlation.
Burst detection methods have been used in financial markets contexts. Burst detection approaches proposed for financial and stock markets treat events as news, messages or any other information formats. Events in such contexts are not suitable for analysis of the operation of a communication system, or for fault diagnosis in a communication system.